Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

improve precompilation coverage #33006

Merged
merged 1 commit into from
Aug 26, 2019
Merged

improve precompilation coverage #33006

merged 1 commit into from
Aug 26, 2019

Conversation

KristofferC
Copy link
Member

@KristofferC KristofferC commented Aug 21, 2019

With this, startup time is back to normal and the time to prompt (measured with the patch in #32971 (comment)) is significantly improved, although not yet completely back to 1.1 levels:

1.1

Generating precompile statements... 1082 generated in 179.581295 seconds (overhead 141.594243 seconds)
./julia -e ''  0.14s user 0.09s system 107% cpu 0.211 total
./julia  0.42s user 0.16s system 191% cpu 0.302 total

1.2

Generating precompile statements... 863 generated in 130.453900 seconds (overhead 100.843763 seconds)
./julia -e ''  0.18s user 0.09s system 124% cpu 0.222 total
./julia  1.09s user 0.19s system 138% cpu 0.929 total

PR

Generating precompile statements... 4087 generated in 130.619177 seconds (overhead  98.529712 seconds)
./julia -e ''  0.13s user 0.08s system 105% cpu 0.208 total
./julia  0.60s user 0.18s system 186% cpu 0.419 total

Probably good enough to say that it fixes #32971 after being backported

- move the place where --trace-compile outputs precompile statement to a location that catches more cases
- tweak the REPL code to be more amenable to precompilation in light of
- instead of trying to encode all the rules where the precompile emitter
  fails (#28808) just try to precompile and do nothing if it fails.
@tkoolen
Copy link
Contributor

tkoolen commented Aug 21, 2019

Just wondering: could this also explain JuliaLang/PackageCompiler.jl#188, which came up after PackageCompiler switched from using SnoopCompile to directly using --trace-compile?

@KristofferC
Copy link
Member Author

KristofferC commented Aug 21, 2019

I guess it could, yeah.

@KristofferC
Copy link
Member Author

Barring comments, I plan to merge this in a day or so.

Copy link
Member

@c42f c42f left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks reasonable to me; mostly it's just code movement.

It seems sensible to consolidate all precompile / snoop compile printing together. I don't know the correct location for that but your tests look good.

@error "Failed to precompile $statement"
rethrow()
# See #28808
# @error "Failed to precompile $statement"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be left in at @debug level?

@KristofferC KristofferC mentioned this pull request Aug 25, 2019
36 tasks
@@ -765,15 +765,21 @@ setup_interface(
repl::LineEditREPL;
# those keyword arguments may be deprecated eventually in favor of the Options mechanism
hascolor::Bool = repl.options.hascolor,
extra_repl_keymap::Union{Dict,Vector{<:Dict}} = repl.options.extra_keymap
extra_repl_keymap::Any = repl.options.extra_keymap
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nospecialize? Just asserting that it's an Any doesn't prevent the compiler from trying to specialize it. Same for the one below.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this takes care of that:

@nospecialize # use only declared type signatures

@KristofferC KristofferC merged commit c0478d8 into master Aug 26, 2019
@delete-merged-branch delete-merged-branch bot deleted the kc/moar_precompile branch August 26, 2019 10:12
@KristofferC KristofferC mentioned this pull request Aug 26, 2019
9 tasks
KristofferC added a commit that referenced this pull request Aug 26, 2019
- move the place where --trace-compile outputs precompile statement to a location that catches more cases
- tweak the REPL code to be more amenable to precompilation in light of
- instead of trying to encode all the rules where the precompile emitter
  fails (#28808) just try to precompile and do nothing if it fails.

(cherry picked from commit c0478d8)
KristofferC added a commit that referenced this pull request Aug 26, 2019
- move the place where --trace-compile outputs precompile statement to a location that catches more cases
- tweak the REPL code to be more amenable to precompilation in light of
- instead of trying to encode all the rules where the precompile emitter
  fails (#28808) just try to precompile and do nothing if it fails.

(cherry picked from commit c0478d8)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler:latency Compiler latency compiler:precompilation Precompilation of modules
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Julia 1.2 start-up is slower than 1.1
5 participants